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Executive  Summary 

The  Distributed  Interactive  Fire  Mission  II  (DIFMII)  Concept  Evaluation  Program  (CEP)  was  an 
experimental  exercise  conducted  at  the  Mounted  Warfare  Test  Bed  (MWTB)  at  Fort  Knox  KY  from 
September  28  to  October  14,  1999.  The  experiment  was  performed  as  Delivery  Order  (DO)  #01 16 
under  the  Lockheed  Martin  Advanced  Distributed  Simulation  Technology  II  (ADST  II)  Contract 
a  ministered  by  the  U.S.  Army  Simulation,  Training,  and  Instrumentation  Command  (STRICOM). 

The  Mounted  Maneuver  Battle  Lab  (MMBL),  Fort  Knox,  KY  sponsored  the  experiment  The 
experiment  utilized  a  synthetic  environment  that  employed  virtual  simulations  to  depict  an  Armor 
Platoon  executing  six  basic  platoon-level  scenarios  in  realistic  combat  situations  in  various 

|eQXfnwerw  configuratlons-  The  scenarios  were  executed  on  the  Synthetic  Theatre  of  War  -  Europe 
(STOW-E)  terrain  database  using  Movement  to  Contact  vignettes.  These  scenarios  were  designed 
into  a  twenty-e.ght-tra.l  matrix  to  induce  the  platoon  leader  to  make  tactical  decisions,  which  affected 
battle  outcomes.  The  objectives  of  the  effort  were: 

a)  th®°Perational  effectiveness  of  an  Armor  Platoon  equipped  with  alternative 
UIPM  functionality  applications  during  threat  engagements  in  a  Force  XXI  or  Armv  After 
Next  (AAN)  tactical  environment. 

b)  To  identify  software  requirements  essential  to  implement  DIFM  alternatives  at  Platoon  level 
operations. 

c)  To  serve  as  a  foundation  for  subsequent  evaluation  of  DIFM  growth  to  support  Battalion 

level  Beyond  Line-Of-Sight  (BLOS),  target  intensive,  and  conceivably  combined  arms  fire 
distribution. 

DIFM  is  a  concept  describing  integrated  multi-agent  (distributed)  automated  fire  control  systems 
capable  of  accepting  target  information  from  multiple  sources,  determining  available  firing  platforms 
(based  on  location  activity  and  obstacle  noninterference),  tasking  unencumbered  shooters,  passing 
fire  solution  data  to  assigned  platforms,  displaying  shooter  target  acquisition  indicators  to  facilitate 
search  and  rapid  engagement  procedures,  and  consequently  optimize  shooter  survivability.  The 
objective  system  will  encompass  computation,  display,  communication  functionality,  and  will  have 
the  capacity  to:  a)  automatically  assign  search  sectors  to  all  shooters,  prioritize  targets,  cue  incoming 
firing  data,  cue  engagement  area  limits  (in  the  sight  reticule),  cue  no-responsibility  (other-assigned) 
targets  for  individual  shooters,  and  automatically  locate  and  slew  onto  assigned  targets  at  the 
individual  shooter  level  for  target  assignment  functions;  and  b)  determine  kill  zones  and  optimal 
firing  positions  (through  terrain  analysis)  for  subordinate  units  alerted  to  maneuvering  opponents 
project  sector  entry  points  of  targets  for  vehicle  commanders’  early  engagement,  track  friendly  forces 
for  improved  identification,  and  prioritize  targets  for  course-of-action  determination  in  a  planning 
context.  Integration  with  programmed  Force  XXI  Battle  Command  Brigade  and  Below  (FBCB2) 
unc  lonality  is  anticipated.  On  implementation,  noted  functionality  is  expected  to  enhance  target 
assignment  efficiency  by  eliminating  extended  sector  search  times  and  reducing  required  time  for 
manual  target  assignment  through  Frequency  Modulation  (FM)  voice  radio.  The  system  also  is 
estimated  to  support  immediate  application  of  individual  firing  platforms  for  massing  of  direct  fires 
on  single  or  multiple  targets.  5 

"  CEP  “Peri"*™  was  conducted  at  the  Mounted  Warfare  Test  Bed  (MWTB),  Fort  Knox 
and'  J5d  'l  c  employed  a  combination  of  existing  MWTB  assets,  such  as  Ml  A2  manned  simulators 

(ModSAF),  as  well  as  a  version  of  the  existing  Rotorcaft 
Pilot  s  Associate  (RPA)  simulation,  modified  for  ground  (tank)  combat  use. 
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Development  of  the  software  modifications  and  the  initial  integration  of  software  models  were 
conducted  at  the  Lockheed  Martin  Federal  Systems  (LMFS)  facility  in  Owego,  NY  from  May  24  to 
September  17,  1999.  The  final  integration  phase  was  completed  at  the  MWTB  from  September  20- 
24, 1999. 

In  accordance  with  the  Government  Statement  of  Work,  the  experiment’s  training  and  test  trial 
window  was  two  (2)  weeks.  This  two  week  period  included  time  to  execute  the  trial  run  matrix  and 
additional  time  scheduled  for  make-up  of  non-validated  runs,  if  required. 

The  entire  trial  run  matrix  was  executed  within  the  allocated  two  weeks  with  no  additional  time 
required  for  make-up  of  non-validated  runs.  As  a  result,  a  portion  of  the  second  week  was  made 
available  for  additional  excursion  runs. 

In  accordance  with  the  Government  SOW,  this  Final  Report  includes  a  description  of  the  experiment, 
its  conditions  and  conduct,  and  lessons  learned.  This  report  addresses  the  interconnectivity  of 
simulation  systems,  modifications  to  both  ModSAF  and  the  manned  simulators,  and  the  integration 
of  Government  Furnished  software  models.  This  report  does  not  include  discussion  of  data  analysis 
nor  conclusions  as  to  whether  the  customers)  achieved  the  objectives  of  the  experiment. 


User  or  disclosure  of  the  information  on  this  page  is  subject  to  the  restrictions 
referenced  on  the  cover  page  of  this  report. 
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1.  INTRODUCTION 

1.1  Purpose 

The  purpose  of  this  Final  Report  is  to  document  the  ADST  II  effort,  which  supported  DIFM.  This 
report  includes  a  full  description  of  the  experiment,  its  conditions,  and  lessons  learned. 


1.2  Contract  Overview 

The  Distributed  Interactive  Fire  Mission  II  (DIFMII)  Concept  Evaluation  Program  (CEP)  was  an 
experimental  exercise  conducted  at  the  Mounted  Warfare  Test  Bed  (MWTB)  at  Fort  Knox,  KY  from 
September  28,  to  October  14,  1999.  The  experiment  was  performed  as  Delivery  Order  (DO)  #01 16 
under  the  Lockheed  Martin  Advanced  Distributed  Simulation  Technology  II  (ADST  II)  Contract 
administered  by  the  U.S.  Army  Simulation,  Training,  and  Instrumentation  Command  (STRICOM). 
The  Mounted  Maneuver  Battle  Lab  (MMBL),  Fort  Knox,  KY  sponsored  the  experiment. 

1.3  Experiment  Overview. 

The  DIFM  concept  arose  from  a  need  for  superior  target  sorting  and  fire  distribution  capabilities  as 
advanced  munitions  and  commanders'  increased  battlespace  responsibilities  were  projected  for  the 
emerging  battlefield.  Given  expected  increases  in  operating  tempo,  the  ability  to  rapidly  and 
accurately  sort  targets  and  assign  fire  missions  to  intermittently  available  (due  to  prior  fire  missions  or 
ammunition  availability)  and  generally  moving  firing  platforms  was  recognized  as  a  critical 
requirement  to  facilitate  the  required  performance  on  the  technology-saturated  battlefield.  Although 
“end  functionality”  to  manage  the  task  was  identified  in  the  Force  XXI  Battle  Command  Brigade  and 
Below  (FBCB2)  User  Functional  Description  (UFD),  details  of  serial  functionality  performance  and 
functionality  distribution  in  an  operational  context,  and  the  operational  effectiveness  resulting 
therefrom,  remained  sketchy  and  unconfirmed.  Therefore,  an  ongoing  assessment  of  alternative 
functionality  applications  and  their  location  was  prescribed  for  further  definition  of  the  capability  and 
force  integration  characteristics  necessary  to  implement  DIFM  system  integration  for  maximum 
tactical  benefit. 

DIFM  is  a  concept  describing  integrated  multi-agent  (distributed)  automated  fire  control  systems 
capable  of  accepting  target  information  from  multiple  sources,  determining  available  firing  platforms 
(based  on  location,  activity,  and  obstacle  noninterference),  tasking  unencumbered  shooters,  passing 
fire  solution  data  to  assigned  platforms,  displaying  shooter  target  acquisition  indicators  to  facilitate 
search  and  rapid  engagement  procedures,  and  consequently  optimize  shooter  survivability.  The 
objective  system  will  encompass  computation,  display,  communication  functionality,  and  will  have 
the  capacity  to:  a)  automatically  assign  search  sectors  to  all  shooters,  prioritize  targets,  cue  incoming 
firing  data,  cue  engagement  area  limits  (in  the  sight  reticule),  cue  no-responsibility  (other-assigned) 
targets  for  individual  shooters,  and  automatically  locate  and  slew  onto  assigned  targets  at  the 
individual  shooter  level  for  target  assignment  functions;  and  b)  determine  kill  zones  and  optimal 
firing  positions  (through  terrain  analysis)  for  subordinate  units  alerted  to  maneuvering  opponents, 
project  sector  entry  points  of  targets  for  vehicle  commanders’  early  engagement,  track  friendly  forces 
for  improved  identification,  and  prioritize  targets  for  course-of-action  determination,  in  a  planning 
context.  Integration  with  programmed  FBCB2  functionality  is  anticipated.  On  implementation,  noted 
functionality  is  expected  to  enhance  target  assignment  efficiency  by  eliminating  extended  sector 
search  times  and  reducing  required  time  for  manual  target  assignment  through  FM  voice  radio.  The 
system  also  is  estimated  to  support  immediate  application  of  individual  firing  platforms  for  massing 
of  direct  fires  on  single  or  multiple  targets. 
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The  D1FM  II  CEP  experiment  was  conducted  at  the  Mounted  Warfare  Test  Bed  (MWTB),  Fort  Knox, 
KY.  The  effort  employed  a  combination  of  existing  MWTB  assets,  such  as  Ml  A2  manned  simulators 
and  Modular  Semi-Automated  Forces  (ModSAF),  as  well  as  a  version  of  the  existing  Rotorcraft 
Pilot’s  Associate  (RPA)  simulation,  modified  for  ground  (tank)  combat  use. 

1.4  Technical  Overview 

The  technical  approach  to  the  DIFM  II  experiment  involved  the  analysis  of  the  initial  DIFM 
experiment,  analysis  of  new  requirements  for  DIFM  II,  enhancements  to  the  initial  software  from  the 
previous  effort,  and  the  development  of  new  software  to  meet  the  DIFM  II  requirements.  The  initial 
software  development  and  enhancement  effort  took  place  at  the  LMFS  facility  in  Owego,  NY  from 
May  24  to  September  17,  1999.  During  this  initial  phase  one  Technical  Interchange  Meeting  (TIM) 
was  conducted  at  the  Owego,  NY  facility  and  one  at  the  MWTB.  The  purpose  of  the  TIMs  was  to 
assess  the  development  efforts  to  date  and  obtain  customer  approval  and  additional  guidance.  Upon 
completion  of  the  initial  software  development,  the  software  and  its  associated  hardware  were 
shipped  and  reinstalled  at  the  MWTB.  It  took  five  days  to  complete  the  on-site  integration  at  the 
MWTB.  Once  the  synthetic  environment  functional  tests  were  completed,  the  engineers  conducted 
troop  training  and  a  Pilot  Test.  A  Test  Readiness  Review  (TRR)  was  held  on  September  28,  1999. 
At  the  TRR  permission  was  given  to  freeze  the  software  configuration  and  approval  was  given  to  start 
the  experiment,  which  began  on  September  28,  1999.  The  actual  experiment  period  ran  through 
October  14,  1999  during  which  30  different  iterations  were  executed  using  six  basic  scenarios.  The 
trial  matrix  was  completed  ahead  of  schedule  and  the  additional  time  was  used  to  conduct  excursion 
runs. 

2.  Applicable  Documents 
2.1  Government 

-ADST  II  Work  Statement  for  Distributed  Interactive  Fire  Mission  II  (DIFMII)  Concept  Evaluation 
Program  (CEP),  April  26,  1999,  AMSTI-99-W041,  Version  1.0 


2. 2  Non-Governmen  t 

-  None 

3.  System  Description 

3.1  System  Configuration  and  Layout 

The  Mounted  Warfare  Test  Bed  at  Fort  Knox,  KY,  contains  a  variety  of  vehicle  simulators,  networks, 
Semi- Automated  Forces  (SAF)  capabilities,  displays  for  monitoring  the  battlefield,  utilities  to 
facilitate  exercises,  automated  data  collection  capabilities,  and  data  reduction  and  analysis 
subsystems.  The  MWTB  simulation  and  support  platforms  used  for  DIFM  II  are  depicted  in  Figure  1 . 


User  or  disclosure  of  the  information  on  this  page  is  subject  to  the  restrictions 
referenced  on  the  cover  page  of  this  report. 
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Figure  1  DIFM  Floor  Plan 

The  experiment  was  conducted  using  assets  interconnected  on  Ethernet  Local  Area  Networks  (LANs) 
via  thin  net  cable.  Simulation  assets  used  Distributed  Interactive  Simulation  (DIS)  2.03  protocol 
Table  1  lists  assets  used  at  the  MWTB.  F 


3 


ADST-II-CDRL-DIFMII-9900236 
1  November  1999 


ADST II  ASSET 

PURPOSE 

PROTOCOL 

Modified  Ml  A2  Simulators  (2) 

M1A2  Simulator  for  Tank  Platoon  Leader 

and  Tank  Platoon  Sergeant 

DIS 

Stealth 

Battlefield  Display  for  observation  of  the 
battlefield 

DIS 

ModSAF  Workstations  (2) 

Semi-Automated  Forces  for  OPFOR,  &  two 
BLUFOR  M1A2  Tanks 

DIS 

Plan  View  Display 

Terrain  Map  of  the  battlefield  for  Exercise 
Control 

DIS 

Data  Loggers 

Record  of  DIS  PDUs  for  Data  Collection  & 
Analysis 

DIS 

DIS  Time  Stamper 

Time  Stamp  of  DIS  PDUs  for  Data 
Collection  &  Analysis 

DIS 

Table  1  MWTB  Assets 


3.2  Description  of  System  Components 

This  section  discusses  the  description,  functionality  and  operation  of  the  system  components,  which 
includes  the  Government  Furnished  Equipment  (GFE)  models  and  their  integration  with  the  hardware 
at  the  MWTB. 

3.2.1  M1A2  Simulator 

Two  M1A2  simulators  were  used  for  DIFM  IE  The  simulators  represented  the  Tank  Platoon  Leader 
and  the  Platoon  Sergeant’s  tank  as  part  of  an  Armor  Platoon.  The  simulators  were  modified  to 
replicate  the  DIFM  II  hardware.  The  Tactical  Display  was  mounted  to  the  left  of  the  Tank 
Commander  (TC)  in  the  manned  simulators.  It  provided  the  commander  with  a  color  map  showing 
accurate  terrain  profile  and  route  information  data,  timely  Platoon  member  locations,  threat  warnings, 
and  map  overlays.  The  Wingman  GUI  device  was  installed  to  provide  the  driver  with  a  color  moving 
map  display  overlaid  with  his  scan  sector,  route  and  friendly  and  enemy  locations. 


3.2.2  Commander’s  Decision  Aid 

The  Commander’s  Decision  Aid  (DA)  was  a  version  of  the  Rotorcraft  Pilot’s  Associate  Decision 
Aiding  System,  modified  for  ground  (tank)  combat.  The  DA  consisted  of  software  executing  in  a 
Real-Time  Symmetric  Multiprocessor  (RTSMP)  computer.  The  RTSMP,  developed  for  RPA, 
consists  of  eight  150MHz  PowerPC  processors  and  both  local  and  global  memory.  The  SGI  processor 
consists  of  12  150MHz  R4000  processors.  Both  the  RTSMP  and  the  SGI  were  provided  by  AATD. 
The  primary  functions  provided  by  the  DA  were: 

a.  Common  Relevant  Picture  (CRP)  -  The  DA  provided  a  CRP  of  the  battlespace,  superimposing 
the  location  and  type  of  all  known  enemy  and  friendly  units  on  plan  and  perspective  digital 
maps.  This  picture  also  depicted  the  commander’s  battle  graphics  (phase  lines,  zone 
boundaries,  engagement  areas,  battle  positions,  routes  and  scan  sectors.) 


User  or  disclosure  of  the  information  on  this  page  is  subject  to  the  restrictions 
referenced  on  the  cover  page  of  this  report. 
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b.  Mission  Replanner  -  Upon  receipt  of  a  change  of  mission  message,  the  DA  recommended  a 

new  mission  plan  to  the  crew.  The  mission  plan  included  battle  positions  and  routes. 

c.  Scan  Sectors  -  The  DA  allowed  the  battle  commander  to  “draw”  scan  sectors  for  each 

teammate  and  when  completed  assign  and  distribute  them  to  the  team. 

d.  Battlefield  Assessor  -  DA  continually  monitored  the  battlefield  situation.  Whenever  changes 
in  the  battlefield  situation  warranted  modifications  to  the  route  plan,  appropriate  plan 
modifications  were  recommended  to  the  crew. 

e.  Wignman  GUI  -  The  Wingman  Graphical  User  Interface  (GUI)  software  was  developed  by 
Kouwen-Hoven  &  Hoskins  in  conjunction  with  Lockheed  Martin  Federal  Systems  for  the 
Distributed  Interactive  Fire  Mission  (DIFM)  Program.  The  Wingman  GUI  device  provides  a 
situational  awareness  display  that  can  be  used  by  a  tank  driver  or  tank  commander.  This  GUI 
provides  a  display  of  platoon  vehicles  (“own  vehicle”  and  wingmen),  battlefield  entities,  the 
route  plan,  “own  vehicle”  scan  sector  and  the  current  engagement  area.  The  Wingman  GUI 
displays  the  scan  sector  assigned  to  the  vehicle  in  which  it  is  located  (the  scan  sector  is  not 
labeled  on  the  GUI  display). 

3.2.3  ModSAF  Operations 

ModSAF  version  4.0  was  used  for  DIFM.  ModSAF  was  used  for  Blue  Force  (BLUFOR)  round-out 
and  Opposing  Force  (OPFOR).  BLUFOR  ModSAF  provided  the  two  additional  tanks  required  to 
round-out  the  Armor  Platoon.  OPFOR  were  provided  in  a  configuration  of  a  Motorized  Rifle 
Company  to  complete  the  scenario  requirements.  ModSAF  was  used  on  two  SGI  Indy  platforms. 

3.2.4  Data  Logger 

The  Data  Logger  is  an  ADST II  asset  that  captures  the  network  traffic  and  places  the  data  packets  on 
a  disk  or  tape  file.  The  Data  Logger  performs  the  following  functions: 

a.  Packet  Recording  -  Receives  packets  from  the  DIS  network,  time  stamps  and  then  writes  to  a 
disk  or  tape. 

b.  Packet  Playback  -  Packets  from  a  recorded  exercise  can  be  transmitted  in  real  time  or  faster 
than  real  time.  The  Data  Logger  can  also  suspend  playback  (freeze  time)  and  skip  backward 
or  forward  to  a  designated  point  in  time.  The  logger  can  be  controlled  directly  from  the 
keyboard  or  remotely  from  the  Plan  View  Display  (PVD).  Playback  is  visible  to  any  device 
on  the  network  (PVD,  Stealth  Vehicle,  a  vehicle  simulator,  etc.). 

c.  Copying  or  Converting  -  Files  are  copied  to  another  file,  which  can  be  on  the  same  or  a 
different  medium;  and  files  from  the  older  version  of  the  Data  Logger  can  be  converted  to  a 
format  compatible  with  the  current  version  of  the  Data  Logger. 

For  the  exercise,  two  data  loggers  were  employed  to  capture  the  exercise.  The  two  data  loggers  were 
placed  on  the  DIS  net  to  capture  all  DIS  PDUs  for  analysis.  These  two  loggers  used  Sun  IPX  systems 
with  48  MB  RAM,  1  GB  Hard  drive,  and  the  Sun  OS  4.1.3  operating  system.  One  data  logger  was 
designated  as  a  back  up  and  was  not  needed. 

3.2.5  Sensor  Server 

The  sensor  server  was  a  SUN  Sparc  20  workstation.  It  was  running  modified  ModSAF  3.0  software 
that  would  receive  DIS  2.03  data  packets  on  User  Datagram  Protocol  (UDP)  port  3000  (real  world) 
and  pass  them  to  UDP  port  3010  (sensed  world)  if  they  were  friendly  entities  or  enemy  entities  that 
had  been  sensed  by  blue  intelligence.  This  provided  the  ability  to  take  a  “standard”  simulation  tool, 
such  as  a  Stealth  or  ModSAF  PVD,  and  use  it  as  a  more  enhanced  C2  system,  displaying  Blue  Forces 
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(BLUFOR)  Situation  Awareness  (SA)  as  well  as  sensed/detected  OPFOR.  Real  world  and  sensed 
world  used  the  same  physical  network.  Additional  technical  data  on  the  Sensor  Served  can  be  found 
in  the  BCR  III  Version  Description  document  ADSTII-CDRL-BCRIII-99002 1 9. 

3.2.6  Network  Router 

The  Network  Router  is  an  application  that  allows  different  subnets  to  be  joined  according  to  rules 
appropriate  to  the  experiment.  The  DIFM  II  experiment  called  for  Scan  Sector  Limit  Indicators  (Lis) 
that  are  visible  from  the  manned  simulators.  These  Lis  provide  an  indication  to  the  simulator's  crew 
of  the  commander's  desired  scan  limits.  Each  simulator's  Lis  should  only  be  visible  from  that 
simulator. 

For  the  DIFM  II  experiment,  the  Network  Router  joined  the  following  four  subnets: 

a.  Overall  simulation  network  (port  3000).  This  network  contains  Protocol  Data  Units  (PDUs)  for 

all  simulated  vehicles.  It  does  not  contain  any  PDUs  from  Posts.  No  simulations  are  directly 
attached  to  this  network. 

b.  Ml  A2  network  (port  3081).  This  network  contains  contains  PDUs  for  all  simulated  vehicles. 

It  also  contains  the  LIs  intended  for  the  Ml  A2  manned  simulator.  The  Ml  A2  simulator  is 
directly  attached  to  this  network. 

c.  ModSAF  network  (port  3033).  This  network  contains  PDUs  for  all  simulated  vehicles.  It  also 

contains  the  LIs  intended  for  any  ModSAF  vehicle.  The  ModSAFs  are  directly  attached  to 
this  network. 

The  process  starts  when  the  DIFM  sends  a  Scan  Sector  PDU,  which  is  defined  as: 
typedef  struct  { 

DI  S203_PDU_HEADER_RECORD  pdu_header; 

DIS203_ENTITY  IDJR.ECORD  senderjd; 

DI  S203  ENTITY JDRECORD  targetjd; 

uint32  state; 

uint32  pad; 

DI  S203  WORLD  COORDINATES  RECORD  origin; 

DI  S203_WORLD  COORDINATES  RECORD  left_ray; 
DIS203_WORLD_COORDINATES_RECORD  right_ray; 
float32  field_of_view; 

float32  heading; 

float32  range; 

}  DI  S203  SC AN_S  ECTOR  PDU ; 

#define  DIS203_SCAN_SECTOR_PDU_KIND  186 
#define  SCAN_SECTOR_STATE_ACTIVE  0 
#define  SCAN_SECTOR_STATE  INACTIVE  1 

The  important  fields  are  targetjd  (the  simulator  that  should  see  the  LIs),  and  the  origin,  leftray,  and 
right  ray  locations.  When  the  Network  Router  receives  a  Scan  Sector  PDU,  it  calculates  LI  locations 
using  the  origin,  left  ray,  and  right_ray  locations.  The  left  LI  will  be  200  meters  from  the  origin 


User  or  disclosure  of  the  information  on  this  page  is  subject  to  the  restrictions 
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along  the  origin-leftray  vector.  If  there  is  no  intervisibility  to  that  location,  a  new  location  closest  to 
the  origin  will  be  determined,  until  intervisibility  exists.  The  process  is  repeated  for  the  right  LI. 
EntityState  PDUs  for  the  Lis  are  then  transmitted  on  the  appropriate  subnet.  The  Lis  enumeration  is 
that  of  a  Line  Pair  Target  Board.  EntityState  PDUs  will  be  periodically  generated  for  each  LI  until  a 
Scan  Sector  PDU  is  received  with  the  state  field  equal  to  SCAN  SECTOR  STATE  INACTIVE.  The 
network  diagram  is  shown  in  figure  2.  The  manned  simulator  receives  the  PDU,  and  tells  its  IG  to 
paint  the  Limit  Indicators  in  the  Gunner’s  sight. 


DIFM 

Functional  Network  Diagram 


Figure  2.  Network  Diagram 


3.2.7  Time  Stamper 

The  MWTB  provided  a  Time  Stamper,  which  consisted  of  a  video  time  code  generator.  This  time 
code  generator  produced  time  data  in  days,  since  1  January,  in  hour/min/sec  format.  It  also  ran  on  an 
IBM-compatible  Personal  Computer  (PC).  The  PC  was  programmed  to  read  the  video  time  code, 
convert  the  time  data,  and  then  generate  a  Time  PDU  which  was  then  issued  on  the  DIS  network  each 
second.  This  provided  the  real  world  clock  time  on  the  logged  data  to  assist  in  subsequent  analyses. 
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3.2.8  Stealth  System 

The  SGI  ONYX  RE  Stealth  (Level  II IG)  was  used  during  DIFM  II  with  the  M1A2  simulators.  The 
Stealth  gives  the  Observer/Controller  (O/C)  personnel  a  “window”  into  the  virtual  battlefield  allowing 
them  to  make  covert  observations  of  the  action  occurring  during  the  scenario.  In  addition,  through 
the  use  of  the  data  logger,  the  Stealth  gives  observers  and  analysts  an  After  Action  Review(AAR) 
capability.  The  Stealth  is  a  visual  display  platform  that  consists  of  a  PVD,  various  input  devices,  and 
three  video  displays  that  provide  the  operator  with  a  panoramic,  3D  view  of  the  battlefield. 

The  Stealth  permits  the  controller  to  fly  around  the  virtual  battlefield  and  view  the  simulation  without 
interfering  with  the  action.  The  features  of  the  Stealth  allow  the  observer  to  survey  the  virtual 
battlefield  from  a  variety  of  different  perspectives,  including: 

a.  Tethered  View  -  Allows  the  user  to  attach  unnoticed  to  any  vehicle  on  the  virtual 
battlefield. 

b.  Mimic  View  -  Places  the  user  in  any  vehicle  on  the  virtual  battlefield  and  provides 
the  same  view  as  the  vehicle  commander. 

c.  Orbit  View  -  Allows  the  operator  to  remain  attached  to  any  vehicle  on  the  virtual 
battlefield  and  to  rotate  360°  about  that  vehicle,  while  still  maintaining  the  vehicle  as 
a  center  point  of  view. 

d.  Free  Fly  Mode  -  Permits  independent  3-D  movement  anywhere  in  the  virtual 
battlefield. 

3.2.9  Database  Development 

The  existing  ADST  II  STOW-E  terrain  database  was  used  to  support  the  experiment.  The  database 
was  50  Km  by  50  Km  and  was  used  with  sunshine  and  rain  weather  conditions. 

The  DA  software  utilizes  many  terrain-referenced  databases.  As  designed  for  RPA,  these  databases 
can  all  be  created  from  standard  real  world  Defense  Mapping  Agency  (DMA)  products.  For  DIFM, 
the  STOW-E  database  utilized  data  in  a  format  called  Compact  Terrain  Database  (CTDB).  Because  of 
differences  between  this  simulated  STOW-E  data  format  and  the  format  of  DMA  data  changes  were 
necessary.  This  initial  database  creation  process  resulted  in  a  number  of  alignment  problems  which 
were  resolved  by: 

•  Converting  ARSI  and  ModSAF  GCC  data  to  TCC  for  use  by  DIFM  S/W  directly 

•  Converting  ModSAF  projection  for  STOWE 

•  Modifying  DIFM  C&D  UTM  readout  to  display  5  character  UTM  format 

•  Modifying  DIFM  C&D  UTM  conversion  to  use  UTM  projection 

•  Adding  Tree  Line  features  to  the  DFAD  database  prior  to  creation  of  the  Discernability  database. 

The  Ml  A2  Tank  Simulators  and  the  ModSAF  Players  at  the  MMBL  can’t  drive,  see  or  shoot  through 
the  trees/tree  lines.  On  RPA,  trees  are  not  considered  blocking  terrain.  Therefore,  for  DIFM  DAS, 
functions  that  utilize  terrain  databases  for  computing  LOS  were  modified  to  properly  account  for 
trees: 

•  DIFM  S/W  &  Database  Structure  was  modified  to  utilize  multiple  databases: 

•  Elevation  Data  without  trees  for  plan  view  map,  elevation  contour  lines  and  algorithms  that 
require  ground  elevation 

•  Elevation  Data  with  trees  for  line-of-sight  calculations 

•  Trees  and  buildings  block  line-of-sight  (LOS)  from  friendly  vehicles  to  threats  and  from  threats  to 
friendly  vehicles  and  to  their  planned  routes. 


User  or  disclosure  of  the  information  on  this  page  is  subject  to  the  restrictions 
referenced  on  the  cover  page  of  this  report. 
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•  For  LOS  computations,  the  elevation  of  friendly  and  enemy  vehicles  is  conservatively  set  to  the 
highest  terrain  within  100  meters. 

•  For  LOS  computations,  the  elevation  of  enemy  vehicles  is  conservatively  set  to  the  highest  terrain 
within  100  meters 

•  To  be  “safest”,  the  elevation  of  the  intervening  terrain  and  features  is  assumed  to  be  the  lowest 
altitude  within  100  meters. 

3.2.10  Scenario  Development 

A  series  of  six  test  scenarios  and  one  training  scenario  were  developed  to  support  DIFM  II  (see 
section  4.3).  Each  scenario  contained  four  vignettes  that  depicted  an  Armor  Platoon  conducting 
Movement  to  Contact  (MTC)  tasks.  The  scenarios  included  Operations  Orders  (OPORD), 
Fragmentary  Orders  (FRAGO)  and  overlays  to  support  the  mission.  The  orders  and  overlays  were 
developed  by  the  Mounted  Maneuver  Battle  Lab  and  Lockheed  Martin  Service  Group  (LMSG) 
MWTB  personnel.  The  ModSAF  scenarios  and  graphics  are  on  tape  and  in  the  ADST  II 
Configuration  Management  Library  on  tape  MD0961. 

4.  Conduct  of  The  Experiment 

4.1  Troop  Training 

In  order  to  get  the  maximum  benefit  from  the  Pilot  Test,  a  three  day  period  of  time  was  set  aside  for 
troop  training  to  bring  the  soldiers  and  Research  Assistants  up  to  a  level  of  confidence  on  the  systems 
prior  to  the  Pilot  Test.  This  troop  training  was  conducted  at  the  MWTB  from  September  21  to 
September  27,  1999. 

4.2  Pilot  Test 

The  Pilot  Test  was  conducted  at  the  MWTB  on  September  27,  1999.  During  this  time,  the  soldiers 
used  the  skills  acquired  in  troop  training  to  conduct  tactical  operations  in  a  scenario  specially 
designed  to  stress  the  systems  and  the  soldier’s  skills.  During  this  time  special  attention  was  given  to 
focus  on  technical  anomalies  that  appeared.  No  issues  came  up  in  the  Pilot  Test. 

Following  the  Pilot  Test,  a  time  was  set  aside  to  conduct  a  TRR  to  discuss  the  status  of  the  system. 
The  TRR  was  held  on  September  28,  1999.  At  the  TRR  no  issues  emerged. 

4.3  Experiment  and  Trial  Runs 

The  trial  runs  for  the  experiment  began  on  September  28,  1999.  The  complete  trial  matrix  for  a  total 
of  30  runs  was  completed  ahead  of  schedule  and  the  remaining  time  was  used  for  additional  excursion 
runs.  The  experimental  unit  was  a  Tank  Platoon.  Manned  entities  were  one  Platoon  Leader  and 
Platoon  Sergeant.  The  remainder  of  the  Platoon  was  provided  by  ModSAF.  Table  2  defines  the 
system  configuration  and  scenario  used  in  each  trial. 
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DIFM  EXPERIMENT  MATRIX 
DIFM2 

RUN  MATRIX 
(10  Sep  99) 


Study  Variables: 

Route  # 

Route  Terrain  Enroute  Contour 


RPA 

Distance 

Character(RTC) 

FRAGOs 

Sunshade 

Lines 

KHH 

Yes 

Short  (10k) 

Simple 

i 

Yes 

Yes 

Yes 

No 

Long  (15k) 

Rough 

2 

No 

No 

No 

Case  Matrix: 


Case  Player  RPA  RTC  Distance  #FRAGO  Sunshade  C  Lines  KHH 


1 

1 

No 

Simple 

Short 

1 

Yes 

No 

No 

2 

1 

No 

Simple 

Short 

1 

Yes 

Yes 

No 

3 

1 

No 

Simple 

Short 

1 

No 

Yes 

No 

4 

1 

No 

Rough 

Long 

1 

Yes 

Yes 

No 

5 

1 

Yes 

Rough 

Long 

1 

Yes 

No 

No 

6 

1 

Yes 

Rough 

Long 

1 

Yes 

Yes 

No 

7 

1 

Yes 

Rough 

Long 

1 

No 

Yes 

No 

8 

1 

Yes 

Rough 

Long 

2 

Yes 

Yes 

No 

9 

1 

Yes 

Rough 

Long 

3 

Yes 

Yes 

No 

10 

1 

Yes 

Rough 

Long 

3 

Yes 

No 

No 

11 

1 

Yes 

Rough 

Long 

3 

No 

Yes 

No 

12 

1 

Yes 

Rough 

Long 

i 

Yes 

No 

Yes 

13 

Yes 

Rough 

Long 

1 

Yes 

Yes 

Yes 

14 

1 

Yes 

Rough 

Long 

1 

No 

Yes 

Yes 

15 

1 

Yes 

Rough 

Long 

3 

Yes 

Yes 

Yes 

16 

2 

No 

Simple 

Short 

1 

Yes 

No 

No 

17 

2 

No 

Simple 

Short 

1 

Yes 

Yes 

No 

18 

2 

No 

Simple 

Short 

1 

No 

Yes 

No 

19 

2 

No 

Rough 

Long 

1 

Yes 

Yes 

No 

20 

2 

Yes 

Rough 

Long 

1 

Yes 

No 

No 

21 

2 

Yes 

Rough 

Long 

1 

Yes 

Yes 

No 

22 

2 

Yes 

Rough 

Long 

1 

No 

Yes 

No 

23 

2 

Yes 

Rough 

Long 

2 

Yes 

Yes 

No 

24 

2 

Yes 

Rough 

Long 

3 

Yes 

Yes 

No 

25 

2  i 

Yes 

Rough 

Long 

3 

Yes 

No 

No 

26 

2 

Yes 

Rough 

Long 

3 

No 

Yes 

No 

27 

2 

Yes 

Rough 

Long 

1 

Yes 

No 

Yes 

28 

2 

Yes 

Rough 

Long 

1 

Yes 

Yes 

Yes 

29 

2 

Yes 

Rough 

Long 

1 

No 

Yes 

Yes 

30 

2 

Yes 

Rough 

Long 

3 

Yes 

Yes 

Yes 

‘KHH’  indicates  Kouwen-Hoven  &  Hoskins  ‘Peregrine  Map  System’. 

Table  2  Experiment  Matrix 
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5.  Observations  and  Lessons  Learned 

a)  Integrated  Product  Team. 

Observation:  The  Integrated  Product  Team  (IPT)  process  worked  extremely  well. 

Discussion:  This  experiment  was  a  follow-on  to  the  previous  DIFM  effort.  In  the  original  DIFM 
experiment  several  items  were  recommended  for  enhancements.  Due  to  time  and  budget 
considerations  all  the  enhancements  could  not  be  implemented.  Through  the  IPT  process  with  the 
customer  and  the  developer  an  excellent  dialogue  was  established.  The  customer  established  a 
priority  list  and  each  enhancement  was  costed  separately  by  the  developer.  The  cost  elements  and  the 
priority  lost  were  then  combined  and  a  final  list  of  enhancements  was  developed  and  implemented.  It 
was  through  this  process  that  the  best  and  most  cost  efficient  enhancements  were  implemented. 

Lesson  Learned:  The  IPT  is  an  excellent  tool  to  use  throughout  a  program  and  this  effort  should  be 
used  as  an  example  for  future  efforts. 

b)  Terrain  Feature  Impact  on  Intervisibility 

Observation:  Special  processing  implemented  to  consider  trees  and  other  man-made  features  as 
blocking  terrain  significantly  enhanced  functions  that  rely  on  line-of-sight  processing. 

Discussion:  The  RPA  DA  software  does  not  consider  terrain  features  like  trees  when  computing 
exposure  of  one  position  to  another.  RPA  took  this  approach  since  at  altitude,  terrain  features  are 
often  less  of  a  factor;  aviation  sensors  can  often  see  through  the  feature  (RF,  IR);  and  currently 
available  databases  do  not  represent  terrain  features  like  trees  with  much  accuracy.  However,  during 
the  January  1999  DIFM  Experiment  it  was  concluded  that  for  ground  combat  terrain  features  like  tree 
lines  must  be  considered  by  the  DA.  Therefore,  these  features  were  added  to  the  databases  and  special 
processing  implemented  to  handle  them  as  blocking  terrain.  More  details  on  these  databases  and 
processing  are  included  in  section  3.2.9. 

Lesson  Learned:  For  ground  combat,  terrain  features  like  tree  lines  must  be  considered  by  the 
Decision  Aid.  This  will  drive  the  requirement  for  accurate  mapping  of  battlefield  terrain. 

c)  Scan  Sector  IV 

Observation:  Displaying  the  terrain  visible  from  the  vertex  of  each  scan  sector  enhanced  the  ability 
of  the  commander  to  develop  the  attack  plan. 

Discussion:  For  the  January  1999  DIFM  experiment,  a  capability  was  provided  that  allowed  the 
commander  to  create  scan  sectors  for  the  team  and  overlay  them  on  the  tactical  situation  display  / 
digital  map.  This  capability  was  very  useful  to  the  commander,  but  required  either  manual,  or  a 
keystroke  intensive  task  to  analyze  terrain  blockage.  As  an  enhancement  for  this  DIFM  experiment, 
the  Decision  Aid  automatically  computed  and  displayed  the  terrain  visible  from  the  vertex  of  each 
scan  sector. 

Lesson  Learned:  Functions  that  enhance  the  commanders  ability  to  visualize  the  battlefield,  battle 
graphics,  friendly  and  enemy  positions  are  extremely  valuable  in  helping  the  human  operator  make 
better  decisions;  sometimes  more  so  than  more  complex  “fully  automatic”  functions. 

d)  Wingman  GUI 

Observation:  Providing  the  driver  with  his  own  tactical  situation  display  /  map  greatly  enhanced  his 
ability  to  execute  the  plan. 

Discussion:  For  the  January  1999  DIFM  experiment,  the  driver  was  provided  with  a  repeater  display 
of  the  commander’s  tactical  situation  display  /  map.  On  this  display  he  could  see  the  route  only  if  the 
commander  was  not  panned  to  a  different  location.  In  addition,  the  range  scale  was  often  not  set  to 
optimize  the  driver’s  view  around  the  vehicle.  For  this  most  recent  experiment,  a  separate  display, 
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called  the  Wingman  GUI,  was  added  to  the  system,  giving  the  driver  his  own  dedicated  display  with 
independent  pan  and  range-scale  control. 

Lesson  Learned:  Providing  the  driver  with  his  own  display  should  be  strongly  consider  for  any 
future  implementation  of  DIFM  technology. 

e)  Operating  Area 

Observation:  The  rugged  terrain  chosen  for  the  operating  area  detracted  from  evaluation  of  the 
DIFM  DA. 

Discussion:  The  terrain  in  the  mission  operating  area  was  very  rugged.  This  significantly  complicated 
mission  execution  in  the  M1A2  simulators.  For  example,  the  drivers  often  got  their  tanks  “stuck”  or 
“damaged”  enroute  to  the  engagement  areas.  This  increased  the  time  for  each  trial  and,  in  many  cases, 
detracted  from  evaluation  of  the  DIFM  technologies. 

Lesson  Learned:  Choose  operating  area  /  terrain  to  avoid  adding  unwanted  complexities  to  the 
experiment. 

f)  Training 

Observation:  There  is  seldom  too  much  training. 

Discussion:  For  this  DIFM  experiment  only  one  solider  /  operator  was  experienced  from  the  January 
1999  experiment;  the  others  were  new  to  the  system.  Three  days  hands-on  training  was  provided. 
Although  this  training  was  adequate  for  basic  system  operation,  it  failed  to  provide  the  experience 
necessary  to  deal  with  some  of  the  off-nominal,  time  critical  events  that  occurred  during  the 
experiment. 

Lesson  Learned:  The  capabilities  of  digital  technologies  offer  the  promise  of  greatly  improving  force 
effectiveness.  However,  sufficient  training  must  be  provided  to  allow  the  crews  to  correctly  use  the 
technologies  and  in  the  case  of  Decision  Aids,  the  experience  necessary  to  trust  the  technology. 


6.  Conclusion 

The  DIFM  II  experiment  was  a  technically  complex  effort  that  achieved  its  goal.  Enhancements  to 
the  initial  DIFM  software  improved  the  product.  The  enhancements  from  the  initial  DIFM  effort 
included  the  synchronization  of  the  ModSAF  databases,  route  planner  enhancements  and  display 
changes.  The  successful  integration  of  multiple  GFE  software  models  into  the  MWTB  hardware 
provided  the  desired  synthetic  environment  for  the  customers.  This  environment  allowed  them  to 
analyze  and  evaluate  the  resulting  data  to  assist  in  developing  better  force  protection,  increased 
survivability,  and  enhanced  command  and  control  procedures.  Combined,  these  enhancements  will 
better  preserve  the  force  in  combat  operations. 


User  or  disclosure  of  the  information  on  this  page  is  subject  to  the  restrictions 
referenced  on  the  cover  page  of  this  report. 
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7.  Points  of  Contact 


ADST  II  DIFM  Team 


E.G.  Fish 

Project  Director 

407-306-4456 

Chris  Bodenhorn 

Program  Manager  RPA 

607-751-5699 

Janice  Hess 

Lead  Engineer 

607-751-4879 

Steve  Patteson 

Software  Engineer 

607-751-4931 

Don  Appier 

MWTB  Site  Manager 

502-942-1092 

Eberhard  Kieslich 

MWTB  Lead  Engineer 

502-942-1092 

Paul  Monday 

MWTB  Data  Collection 

502-942-1092 

Dan  Schultz 

MWTB  Battlemaster 

502-942-1092 

Charles  West 

MWTB  Asst.  Battlemaster 

502-942-1092 

Don  DeBord 

MWTB  Act  Battlemaster 

502-942-1092 

Tim  Voss 

MWTB  SW  Technician 

502-942-1092 

Rob  Smith 

MWTB  Network  Technician 

502-942-1092 

Ron  Flackler 

MWTB  Image  Generator 

502-942-1092 

Tom  Van  Lear 

MWTB  Technician 

502-942-1092 

STRICOM 

Chris  Metevier 

Project  Director/Engineer 

407-384-3865 

Customer  Points  of  Contact 
Major  Joe  Burns 

MMBL,  Ft  Knox 

502-942-1092 

Ken  Hunt 

MMBL,  Ft  Knox 

502-942-1092 
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Acronym  List 


AAN 

Army  After  Next 

AAR 

After  Action  Review 

ADST 

Advanced  Distributed  Simulation  Technology 

ARPA 

Advanced  Research  Projects  Agency 

ARSI 

ARPA  Reconfigurable  Simulator  Initiative 

BLOS 

Beyond  Line  of  Sight 

BLUFOR 

Blue  Forces 

CDRL 

Contract  Data  Requirements  List 

CEP 

Concept  Evaluation  Program 

CRP 

Common  Relevant  Picture 

CTDB 

Compact  Terrain  Database 

DA 

Decision  Aid 

DMA 

Defense  Mapping  Agency 

DO 

Delivery  Order 

DIFM 

Distributed  Interactive  Fire  Mission 

DIS 

Distributed  Interactive  Simulation 

FBCB2 

Force  XXI  Battle  Command  Brigade  and  Below 

FRAGO 

Fragmentary  Order 

GFE 

Government  Furnished  Equipment 

GUI 

Graphical  User  Interface 

LAT/LONG 

Latitude/Longitude 

LAN 

Local  Area  Network 

LI 

Limit  Indicator 

LMC 

Lockheed  Martin  Corporation 

LMFS 

Lockheed  Martin  Federal  Service 

LMSG 

Lockheed  Martin  Service  Group 

ModSAF 

Modular  Semi- Automated  Forces 

MMBL 

Mounted  Maneuver  Battle  Lab 

MTC 

Movement  to  Contact 

MWTB 

Mounted  Warfare  Test  Bed 

OC 

Observer  Controller 

OPFOR 

Opposing  Forces 

OPORD 

Operations  Order 
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PC 

Personnel  Computer 

PDU 

Protocol  Data  Unit 

POC 

Point  of  Contact 

PVD 

Plan  View  Display 

RPA 

Rotorcraft  Pilot’s  Associate 

RTSMP 

Real-Time  Symmetric  Multiprocessor 

SA 

Situational  Awareness 

SAF 

Semi-Automated  Forces 

SOW 

Statement  of  Work 

STOW-E 

Synthetic  Theater  of  War-Europe 

STRICOM 

(US  Army)  Simulation  Training  and  Instrumentation  Command 

TC 

Tank  Commander 

TIM 

Technical  Interchange  Meeting 

TRR 

Test  Readiness  Review 

HP 

Tactics,  Techniques,  and  Procedures 

UDP 

User  Datagram  Protocol 

UFD 

User  Functional  Description 
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